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Complex XML vocabulary definitions are often easier to comprehend and discuss with others when they 
are expressed graphically. Although existing tools for editing schemas provide some assistance in this 
regard (e.g., Extensibility XML Authority) they are generally limited to a strict hierarchical view of the 
vocabulary structure. More complex structures are often represented in schemas using a combination of 
containment and link references (including ID/IDREF, simple href attributes, and more flexible 
extended XLink attributes). These more object-oriented models of schema definition are more easily 
represented using UML class diagrams [1]. 

The Unified Modeling Language (UML) is the most recent evolution of graphical notations for object- 
oriented analysis and design, plus it includes the necessary metamodel that defines the modeling 
language itself. UML has experienced rapid growth and adoption in the last two years, due in part to its 
vendor-independent specification as a standard by the Object Management Group (OMG). This UML 
standard and metamodel are the basis for a new wave of modeling tools by many vendors. For more 
information and references to these topics, see the Web portal at XMLModeling.com, which was created 
for the purpose of communicating information about the intersection of XML and UML technologies. 

The OMG has also adopted a standard interchange format for serializing models and exchanging them 
between UML tools, called the XML Metadata Interchange (XMI) specification [2]. (XMI is actually 
broader in scope than this, but its use with UML is most prevalent) Many UML modeling tools now 
support import/export using the XMI format, so it's now possible to get an XML document that contains 
a complete UML model definition. This capability is the foundation for the remainder of this white 
paper. Using an XMI file exported from any UML tool, I have written an XSLT transformation that 
generates an XML Schema document from the UML class model definition. 

As an example that demonstrates the benefits of modeling XML vocabularies with UML, I have reverse- 
engineered a substantial part of the UDDI specification [3]. The current UDDI specification (as of 
January 2001) includes an XML Schema definition that is based on an old version of the XML Schema 
draft, well before the out-dated April 7^^ 2000 draft. In contrast, the UDDI schemas described here are 
compliant with the XML Schema Candidate Recommendation, dated October 24, 2000. The reverse 
engineering was accomplished manually, by reading the UDDI specification and creating a UML model 
in Rational Rose. 

This is work in progress! I spent only a few days studying the UDDI specification and schema while 
building this model. I then applied a prototype tool that generates XML Schemas from UML, with the 
goal of regenerating a schema that is semantically equivalent to the one included in the UDDI 
specification. I used the jUDDI client applicafion [4] to query a business description document from 
Microsoft's UDDI repository. That XML document is, of course, represented using elements from the 
UDDI schema. Finally, using the XML Spy 3.5 beta tool, the UDDI instance document was successfully 
validated using the schema generated from this UML model. 
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UML enables definition of a model structure using packages; these are illustrated in a diagram using file 
folder icons, optionally connected with dependency arrows. A high-level view of UDDI and its 
relationship to other specifications is shown in the following figure. The following examples expand the 
contents of the three packages named UDDI, Contact, and Messages in the diagram. 





XSD Datatypes 



«import» 



«XSDschema» 
UDDI 



«include» 



-> 




«import>>.''' 



«jnclude» 



«XSDschema» 

Contact 
(from UDDI) 



" «include» 



«XSDschema» 
Messages 
(from UDDI) 



«XSDschema» 
Substitutions 

(from UDDI) 



UDDI Core Content Model 

The following UML class diagram illustrates all of the core elements from the UDDI specification. 
There are several important points to notice. First, I followed a common software design practice when 
naming the classes by beginning class names with an upper-case letter; the UDDI schema uses lower- 
case letters to begin all element names. Several other prominent XML schemas also adopt the more 
object-oriented naming conventions as used here. This design requires additional UML and schema 
elements to be declared that map lower-case names to their upper-case complexType definitions. 
Second, in order to allow a designer control over the XML schema generation process, the model was 
defined with several UML stereotypes and tagged values (a standard technique that is part of UML). 
Most of these are not shown in this diagram, but they did affect the generated schema. Although you can 
generate a schema from this UML model without using any stereotype extensions, it is unlikely to match 
the structure of a reverse-engineered schema without some fine-tuning. 



David Carlson 



February 2001 



Page 2 



Modeling the UDDI Schema with UML 



BusinessEntity 



name : string 

description [0. *] : Stringl18N 
businessKey : string 
operator : string 
authorizedName : string 



+businessKey 



+businessServices 



0..* 



BusinessService 



name : string 

description [0..*] : String 11 8N 
serviceKey : string 



+serviceKey 



+bindingTemplates 



0.* 



BindingTemplate 



description [0..*] : String 11 8N 
bindingKey : string 



0..1 



«XSDchoice» 
choice 1 



«XSDsimpleType» 
NMTOKEN 



«enumeratjon» 
URLType 



mailto 

http 
https 
ftp 
fax 

phone 
other 



+dlscoveryURLs 



a.* 



+contacts 



DiscoveryURL 



useType : string 



«XSDsimpleType» 
uri Reference 



0..* 



Contact 

(from Contact) 



0..1- 



o.,r 



IdentifierBag 



TModel 



CategoryBag 



0..1 




tModelKey : string 
name : string 

description [0..*] : StringllBN 



0..1 

\+overviewDoc 



TModellnstancelnfo 



description [0. *] : StringllBN 



OverviewDoc 



description [0..*] : StringllBN 
overvlewURL [0..1] : uriReference 



+tModel I nstanceDetails 



+overvjewDoc 
0,.1 



0..1 

+instanceDetails 



InstanceDetails 



description [0..*] : StringllBN 
instanceParms [0..1] : uriReference 



.0..1 



AccessPoint 



URLType : URLType 



«XSDsimpleType» 
string 



StringMSN 



HostingRedirector 



bindingKey : string 



' «XSDattribute» 



CategoryBag 



IdentifierBag 



«XSDtopLevelAttribute» 
lang 

(from XML Attributes) 



fkeyedReference 




+keyedReference 



KeyedReference 



tModelKey : string 
keyName : string 
keyValue : string 



TModelBag 



tModelKey [1.,*] : string 
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I chose the UDDI schema as the subject of this reverse-engineering exercise in part because of its 
complexity. If this can be accomplished successfully, then other projects are also likely to be feasible. In 
addition, if the UML modeling was done as an integral part of the original schema analysis and design, 
then a number of inconsistencies could be resolved and the schema could be generated using fewer 
stereotype extensions. 

XML Schema definitions are shown for four of the UML model classes. These were generated from the 
XMI export of this model using an XSLT stylesheet to execute the transfomnations. They were not 
manually edited. The schema generator also includes full support for generalization (i.e., inheritance) in 
the UML model and produces valid XML Schema definitions using both complexType and simpleType 
derivation. The UML stereotypes and associated tagged values provide control over design issues such 
as: selection of <choice>, <sequence>, or <all> content model for each complexType definition; 
specification of the element order within <sequence> (UML attributes are unordered in the model); 
selecfion of whether UML attributes and association roles are generated as attributes or elements in the 
XML Schema; and control over the way that UML association ends are embedded with or without role 
elements, and as 'ref or 'type' declarations. 



<! 

<! — CLASS: BusinessEntity 





<xs: element name-"BusinessEnti ty " type="uddi : BusinessEntity"/> 
<xs : complexType name="BusinessEntity"> 
<xs : annotation> 

<xs : documentation> 

Describes an instance of a business or business unit. 
</xs : documentation> 
</xs : annotation> 
<xs : sequence> 

<xs: element name="discoveryURLs" minOccurs="0" maxOccurs="l "> 
<xs : complexType> 
<xs : sequence> 

<xs : element ref ="uddi : DiscoveryURL" 

minOccurs="0" maxOccurs="unbounded"/> 

</xs : sequence> 
</xs : complexType> 

</xs : element> 

<xs: element narae="name" type="xsd: string'V> 

<xs: element name="description" type="uddi : StringI18N" 

minOccurs="0" maxOccurs="unbounded" /> 
<xs: element name="contacts " minOccurs="0" maxOccurs="l"> 
<xs : complexType> 
<xs : sequence> 

<xs : element ref =="uddi : Contact " 

minOccurs=" 0 " maxOccur s="unbounded" /> 

</xs : sequence> 
</xs : complexType> 
</xs : element> 

<xs: element name="businessServices" minOccurs='"'0" maxOccurs="l"> 
<xs : complexType> 
<xs : sequence> 

<xs ; element ref ="uddi :BusinessService" 
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ininOccurs=" 0 " maxOccurs="unbounded" /> 

</xs : sequence> 
</xs : complexType> 
</xs : element> 

<xs: element ref ="uddi : Identif ierBag" minOccurs="0" maxOccurs="l"/> 
<xs: element ref ="uddi :CategoryBag" minOccurs="0" maxOccurs="l"/> 

</xs : sequence> 

<xs : attributeGroup ref="uddi : BusinessEntity . att"/> 
</xs : complexType> 

<xs : attributeGroup name="BusinessEntity . att"> 

<xs : attribute name="businessKey" type="xsd : string" use='"required"/> 
<xs : attribute name="operator " type="xsd : string" use="required"/> 
<xs : attribute name="authorizedName" type="xsd: string" use="required"/> 
</xs : attributeGroup> 

^ > 

<! — CLASS: Business.Service — > 

<t ^ > 

<xs : element name="BusinessService" type="uddi : BusinessService"/> 

<xs : complexType name="BusinessService"> 
<xs : annotation> 

<xs : documentation>Describes a logical service type in business terms, 
</xs : documentation> 
</xs : annotation> 
<xs : sequence> 

<xs: element name="name" type="xsd : string" /> 

<xs: element name="description" type="uddi : StringI 18N" 

minOccurs=" 0 " maxOccurs="unbounded" /> 
<xs: element name="bindingTemplates" minOccurs="0" maxOccurs="l"> 
<xs : complexType> 
<xs : sequence> 

<xs : element ref ="uddi : BindingTemplate" 

minOccurs~"0" maxOccurs="unbounded"/> 

</xs : sequence> 
</xs : complexType > 
</xs : element> 

<xs: element ref ="uddi : CategoryBag" minOccurs="0" maxOccurs=" 1 "/> 
</xs : sequence> 

<xs : attributeGroup ref="uddi : BusinessService . att'V> 

</xs : complexType> 

<xs : attributeGroup name="BusinessService . att"> 

<xs rattribute name="serviceKey" type="xsd: string" use=="required"/> 

<xs : attribute name="businessKey" type=="xs : string"/> 
</xs : attributeGroup> 

<t_- ^ 

<! — CLASS: CategoryBag — > 

<1 ^ ,^ > 

<xs : element name=" CategoryBag" type=="uddi : CategoryBag" /> 
<xs : complexType name="CategoryBag"> 
<xs : sequence> 

<xs : element name="keyedRef erence" type="uddi : KeyedRef erence " 

minOccurs=" 0 " maxOccur s="unbounded" /> 
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</xs : sequence> 

<xs : attributeGroup ref ^"uddi : CategoryBag . att " /> 
</xs : complexType> 

<xs : attributeGroup name="CategoryBag . att"/> 



<i__ 

<! — CLASS: KeyedRef erence — ^> 
<i — ^ 



— > 



> 



<xs : element name^"KeyedRef erence" type="uddi : KeyedRef erence"/> 
<xs : complexType name= " KeyedRef erence "> 

<xs : attributeGroup ref="uddi : KeyedRef erence . att"/> 
</xs : complexType> 

<xs : attributeGroup nanie="KeyedRef erence . att"> 

<xs: attribute name="tModelKey" type="xsd : string" use="required"/> 
<xs : attribute name--"keyName" type="xsd : string" use="required"/> 
<xs: attribute name-"keyValue" type="xsd: string" use="required"/> 

</xs : attributeGroup> 
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Contact Package 

These elements related to business contact information are part of the core UDDI schema. However, I 
have created a separate package in this UML model for three reasons. First, it's important to promote the 
separation and reuse of common components. This is a fundamental goal in object-oriented analysis and 
design, and contact or party information is a classic example of common elements required in most e- 
business applications. Second, because this is primarily an educational exercise, I wanted to create a 
second UML package that would be included by the schema transformation tool. Third, and also part of 
the educational goal, this package includes an experimental mapping for multiple inheritance in UML 
models to XML Schema. Schema does not support multiple inheritance. 



Contact 



personName : string 
description [0..*] : string 





Locator 


useType (0..1] : string 


> 

0..* 





5" 



«XSDsimpleType» 
String 

(from XSD Datatypes) 



StreetAddress 



addressLine [0..*] : string 
sortCode : string 



PhoneNumber 



EmaiiAddress 



7^ 



«XSDtopLevelElement» 
contact 



«XSDtopLevelElement» 
address 



«XSDtopLevelElement» 
phone 



«XSDtopLevelElement» 
email 



The Locator class is an abstract class in UML (denoted by its name in italics in the diagram), so it is 
generated to a complexType with an abstract='true' attribute. StreetAddress uses single inheritance, so it 
may use complexType extension to inherit the attributes of Locator in the schema. PhoneNumber 
inherits from both Locator (a complexType) and string (a simpleType drawn from the XSD Datatypes 
package). In this mapping, a simpleType superclass takes precedence and generates the corresponding 
simpleContent child in PhoneNumber. The Locator attributes are copied down and duplicated within the 
content model for PhoneNumber. Finally, all three subclasses include a substitutionGroup attribute that 
allows them to be substituted for Locator within the content of a Contact element. 

As mentioned previously, this model uses upper-case names for the model elements, whereas the UDDI 
schema uses lower-case names. Thus, this model includes four additional classes stereotyped as « 
XSDtopLevelElement» that create lower-case elements in the generated schema (not shown in the 
code examples). These classes are connected with a UML "realization" relationship in this mapping. 
This contact model creates a schema that is slightly more lenient than the original UDDI schema, but it 
successfully validates current UDDI documents and I believe that it more accurately reflects the 
intended conceptual model of UDDI requirements (with the exception of upper/lower-case issues). 
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<i — ^^^^^ ^ 

<!-- CLASS: Locator — > 
<i — 



<xs: element naine="Locator" type=="uddi : Locator"/> 
<xs : complexType name="Locator " abstract="true"> 

<xs : attributeGroup ref="uddi : Locator . att"/> 

</xs : complexType> 

<xs : attributeGroup name="Locator . att"> 

<xs : attribute name="useType" type="xsd: string"/> 
</xs : attributeGroup> 

<!— - - ~> 

CLASS: StreetAddress — > 
<!-- - — > 



<xs: element name-"StreetAddress " type=="uddi : StreetAddress" 

substitutionGroup="uddi : Locator" /> 
<xs : complexType name=" StreetAddress "> 
<xs : annotation> 

<xs : documentation> 

A printable, free-form address. Typed by convention. Sort not used. 
</xs : documentation> 
</xs : annotation> 
<xs : complexContent> 

<xs : extension base="uddi : Locator "> 
<xs : sequence> 

<xs: element name="addressLine" type="xsd : string" 
minOccurs="0" maxOccurs= "unbounded" /> 

</xs : sequence> 

<xs : attributeGroup ref ="uddi : StreetAddress . att " /> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 

<xs : attributeGroup name="StreetAddress . att"> 

<xs: attribute name-"sortCode" type="xsd : string" use="required" /> 

</xs : attributeGroup> 



<! — CLASS: PhoneNumber — > 



<xs: element name-" PhoneNumber" type-"uddi : PhoneNumber" 

substitutionGroup="uddi : Locator"/ > 
<xs : complexType name=" PhoneNumber "> 
<xs : simpleContent> 

<xs : extension base="xsd: string"> 

<xs : attributeGroup ref ="uddi ; Locator . att" /> 
<xs : attributeGroup ref ="uddi : PhoneNumber . att " /> 
</xs : extension> 
</xs : simpleContent> 
</xs : complexType> 

<xs : attributeGroup name=^" PhoneNumber . at t " /> 
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UDDI Message Model 

The UDDI specification is defined by a single schema and that schema also includes elements that are 
the basis for SOAP messages. I split these definitions into two packages in the UML model and both are 
generated into a single schema document. The following diagram shows a few classes that represent a 
small subset of the UDDI message structures. 



+findQua!lfiers 
0.,* 



find business 



name[0..1] : string 
«XSDattribute» generic : string 
«XSDattribute» maxRows : integer 



findQualifier 



0..1/ 



0..1 




IdentifierBag CategoryBag 



^iscoveryURLs 
0 



DIscoveryURL 



TModelBag 



«XSDsimpleType» 
String 

(from XSD Datatypes) 



findQualifier 



BusinessList Businesslnfo 

«XSDattribute» generic : string +businesslnfos ^^^^ ' string 

«XSDattrjbute» operator : string > description [0..*] : string 

«XSDattribute» truncated : boolean O--* «XSDattribute» businessKey : string 



+servicelnfos 



0..* 



\/ 



Servicelnfo 



name : string 

«XSDattnbute» serviceKey : string 
«XSDattribute» businessKey : string 



get_businessDetail 



businessKey [1..*] : string 
«XSDattribute» generic : string 



BusinessDetail 






«XSDattribute» generic : string 
«XSDattribute» operator : string 
«XSDattribute» truncated : boolean 


0..* 

> 


BusinessEntity 







get__serviceDetail 



serviceKey [1..*] : string 
«XSDattribute» generic : string 



ServiceDetail 




«XSDattribute» generic : string 

«XSDattribute» operator : string 
«XSDattribute» truncated : boolean 


BusinessService 
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The remaining examples focus on two of these UDDI messages: getbusinessDetail and 
BusinessDetail. These messages represent a request — response pair in the UDDI protocol and both 
are wrapped in SOAP message envelopes when exchanged by applications. Notice that the 
BusinessDetail includes an association to zero or more BusinessEntity elements, which 
reference the definition listed in the previous section. Notice also that an extra top-level element was 
declared for businessDetail (not shown in the diagram) that maps to the upper-case complexType 
named BusinessDetail in the schema. 



<i — ^ . 

<! — CLASS: get_businessDetail — > 




<xs : element name="get__businessDetail " type="msg: get_businessDetail"/> 
<xs : complexType name="get_businessDetail "> 
<xs : sequence> 

<xs: element name="businessKey" type="xsd: string" 
minOccurs="l" maxOccurs="unbounded"/> 

</xs : sequence> 

<xs : attributeGroup ref ="msg : get__business Detail . att"/> 
</xs : complexType> 

<xs : attributeGroup name="get_businessDetail . att"> 

<xs : attribute name="generic" type="xsd: string" use="required"/> 
</xs : attributeGroup> 

<!„_ — > 

<! — CLASS: BusinessDetail — > 

<1^- ^ ^ ^ ^ — > 

<xs : element name="BusinessDetail" type="msg : BusinessDetail" /> 
<xs : complexType name="BusinessDetail"> 
<xs : sequence> 

<xs : element ref ="uddi : BusinessEntity" 

minOccurs=" 0" maxOccurs="unbounded" /> 

</ xs : sequence> 

<xs : attributeGroup ref ="msg : BusinessDetail . att"/> 
</xs : complexType> 

<xs : attributeGroup name="BusinessDetail . att "> 

<xs : attribute name=="generic" type="xsd : string" use="required" /> 
<xs : attribute name="operator" type="xsd : string" use="required" /> 
<xs: attribute name="truncated" type="xsd:boolean" use="required"/> 

</xs : attributeGroup> 

<i_^ ^ 

<! — CLASS: <<XSDtopLevelElement» businessDetail — > 

<l™- ^ ^ — > 

<xs : element name="businessDetail" type="msg : BusinessDetail" 
subs ti tut ionGroup="msg: Bus inessDet ail "/> 
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Sample UDDI <businessDetail> Document 

When a <get__businessDetail> message is sent to Microsoft's UDDI repository (wrapped in a 
SOAP message envelope), then the following <businessDetail> message is returned. I've removed 
the SOAP envelope elements that wrapped this response message and modified the default namespace 
declaration to assign my test namespace, but otherwise the message is exactly as returned. 



<businessDetail generic="l . 0" operator="Microsof t Corporation" truncated=="f alse" 
xmlns=^"http: / /www . xmlmode ling . com/schemas/uddi " 
xmlns : xsi="ht tp : / /www . w3 . org/2000/lO/XMLSchema-instance" 
xsi : schemaLocation="http : //www . xmlmodeling . coin/schemas/uddi 

uddi,xsd"> 

<!-- Dave Carlson: 

Modified original default namespace from xmlns="urn : uddi-org : api" 

— > 

<businessEntity authorizedName="Martin Kohlleppel" 

businessKey-"007 6B4 68-EB27-42E5-AC09-9955CFF4 62A3 " 
operator^ "Microsoft Corporation"> 
<dis cover yURLs> 

<discoveryURL useType="businessEntity"> 

http: //uddi .microsoft .com/discovery?businessKey=007 6B4 68-EB2 7-4 2E5-AC09- 
9955CFF4 62A3</discoveryURL> 
</dis cover yURLs> 

<name>Microsof t Corporation</name> 

<description xml : lang="en">Sof tware Vendor</description> 
<contacts> 
<contact> 

<personName>Martin Kohlleppel</personName> 
<email>martink@microsof t . com</email> 
</contact> 
</contacts> 
<businessServices> 

<businessService businessKey="007 6B4 68-EB27"~42E5-AC09~9955CFF4 62A3 " 
serviceKey="CC02E21A-2B4E~4FlA-A2C0-5C5952D67231"> 
<name>UDDI Web Services</name> 

<description xml : lang="en">UDDI Registries and Test Sites</description> 
<bindingTemplates> 

<bindingTemplate bindingKey-"2303E7 8 6-68C0-42 6E-A64 6-8E366B4 3F1FD" 
serviceKey="CC02E21A-2B4E-4FlA-A2C0-5C5952D67231"> 
<description xml : lang="en"> 

Microsoft Production UDDI Registry web interface 
</description> 

<accessPoint URLType="http">http : //uddi .microsoft . com</accessPoint> 
<tModel Ins tanceDe tail s> ' 
<tModelInstanceInfo 

tModelKey-"uuid:4CD7E4BC-64 8B-42 6D-9936-44 3EAAC8AE23"> 
<description xml : lang-"en">UDDI Inquiry Service Type</description> 
<ins tanceDe tail s> 

<description xml : lang="en">SOAP URL for inquire</description> 

<instanceParms>http: //uddi .microsoft . com/inquire</instanceParms> 
</ins tanceDe tails> 
</tModelInstanceInf o> 
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<tModel Instance Info 

tModelKey="uuid: 64C756Dl-337 4-4E00-AE83-EE12E38FAE63"> 
<description xml : lang="en">UDDI Inquiry Publication Type 
</de script ion> 
<instanceDetails> 

<description xml : lang="en">SOAP URL for publication</description> 
<instanceParms>https : / /uddi .microsoft . com/publish</instanceParms> 
</instanceDetails> 
</tModel Instance Info 
</tModelInstanceDetails> 
</bindingTemplate> 



</businessService> 
</businessServices> 
<identif ierBag> 

<keyedReference keyName="D-U-N-S" keyValue="08-14 6-684 9" 

tModelKey="uuid:8 609C81E-EElF-4D5A-B202-3EB13AD01823"/> 

</identif ierBag> 

<categoryBag> 

<keyedReference keyName="NAICS : Software Publisher" keyValue="51121" 

tModelKey-"uuid:C0B9FE13-17 9F-413D-8A5B-5004DB8E5BB2'7> 

</categoryBag> 
</businessEntity> 
</businessDetail> 
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